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Foundation Fieldbus: Features and Software Support 


SALVATORE CAVALIERI 


Foundation Fieldbus is an all-digital, serial, two-way com- 
munication system for industrial applications; its specification 
has been developed and administered by a nonprofit orga- 
nization called Fieldbus Foundation Association [1], Please 
note that in this chapter, Fieldbus Foundation will refer to the 
name of the association while Foundation Fieldbus will be 
used for the relevant communication system. 

Since its very beginning. Foundation Fieldbus has 
shown two fundamental and unique (at that time, at least) fea- 
tures: an emphasis on the standardization of the description 
of the devices to be connected to the fieldbus, and the adop- 
tion of both the distributed and centralized link access mech- 
anisms defined by the IEC 61158/ISA SP50 Standardization 
Committee [2-4]. 

This chapter will emphasize the value of the choices 
made by Fieldbus Foundation association in the definition 
of Foundation Fieldbus specifications. Furthermore, the 
main technical features of the communication system will 
be described in detail, allowing the reader to clearly under- 
stand its key points. Finally, a brief look into the software 
support available to the Foundation Fieldbus end users will 
be given. 

PRINCIPLES OF Foundation FIELDBUS 

When the first fieldbus communication systems [5,6] 
appeared on the market, the need to achieve just only one 
fieldbus standard was felt immediately. About 20 years ago, 
the International Electro-technical Commission (IEC) and 
Instrument Society of America (ISA) embarked on a joint 
standardization effort identified by two codes: 61158 on 
the IEC side and SP50 on the ISA one. One of the main 
aims of the joint standardization committee was the defi- 
nition of a unique communication system, able to merge 
the main features of the fieldbuses available on the market 
at that time: FIP [7] and Profibus [8], This aim has been 
reached by the definition of the IEC/ISA type 1 specifica- 
tions [2,3]. 

The not-for-profit Fieldbus Foundation consortium, estab- 
lished in 1994 and representing the major process automation 
industry suppliers and end users worldwide [1], produced the 
definition of the Foundation Fieldbus [9] fully based on the 
above mentioned IEC 61158 type 1 specifications. 


The main cornerstones of Foundation Fieldbus, at the time 
of its definition, are as follows: 

1. The adoption of both the scheduled and token-passing 
access mechanisms at the Medium Access Control 
(MAC) layer; Foundation Fieldbus fully adopted the 
IEC/ISA type 1 approach to provide both the “pre- 
defined scheduling philosophy" of FIP and the “token 
rotation philosophy” of Profibus. Section on technical 
description gives more details about these two funda- 
mental mechanisms. 

2. Emphasis on a standard description of the devices to 
be connected on the fieldbus. This cornerstone allows 
Fieldbus Foundation to guarantee interoperability 
between devices of different vendors. Foundation 
Fieldbus included the definition of data semantic plus 
their configuration and use within the first set of speci- 
fications. Section on open system implementation will 
go deeper on the interoperability issue. 

During this time, Foundation Fieldbus has been enriched 
by new several and useful features. The first of them is related 
to the transmission medium. Beside the original IEC/ISA 
physical medium [2,10], called HI in Foundation Fieldbus, 
Fieldbus Foundation decided to adopt also the High Speed 
Ethernet (HSE) and to integrate Foundation Fieldbus into 
a wireless environment. Another important feature is the 
improvement of interoperability using other standards, dif- 
ferent from the original one. 

A wealth of software support has been produced to help 
the Foundation Fieldbus end users during the last decade. 
Section on software support will give a very brief overview 
on the main tools currently available. 

TECHNICAL DESCRIPTION OF Foundation FIELDBUS 

Foundation Fieldbus is an all-digital, serial, two-way com- 
munication system for industrial applications, with particular 
target on process control environment. 

Foundation Fieldbus specifications include two different 
configurations, HI and HSE. HI (running at 31.25 kbit/s) 
interconnects “field" equipment such as sensors, actuators 
and I/Os; HSE (running at 100 Mbit/s) provides integration 

598 


© 2012 by Bela Liptak 



39 Foundation Fieldbus: Features and Software Support 599 


of controllers (such as DCSs and PECs), HI subsystems (via 
a linking device [LD]), data servers, and workstations. HSE 
is based on standard Ethernet technology to perform its role. 
In detail; 

• HI Foundation Fieldbus communication system is 
mainly devoted to distributed continuous process con- 
trol and to replacement of existing 4-20 m A devices. Its 
communication functionalities, specihcally foreseen 
for time critical applications, are supported by services 
grouped within levels, as in all other OSI-RM open 
system architectures. The number of levels is mini- 
mal, in order to guarantee maximum speed in the data 
handling. Below the Fieldbus Application Fayer, HI 
Foundation Fieldbus directly presents the Data Fink 
layer (DFF), managing access to the communication 
channel. A Physical Fayer deals with the problem of 
interfacing with the physical medium. A Network and 
System Management Fayer is also present. Figure 39.1 
compares the HI Foundation Fieldbus architecture 
against the ISO OSI reference model. 

• HSE Foundation Fieldbus defines an Application 
Fayer and associated management functions, designed 
to operate over a standard Transport Control Protocol 


(TCP)/Unit Datagram Protocol (UDP)/Internet 
Protocol (IP) stack, twisted-pair or fiber-optic - 
switched Ethernet. It is mainly foreseen for discrete 
manufacturing applications, but, of course, it can also 
be used to interconnect HI segments, as well as for- 
eign protocols trough IP/TCP gateways, in order to 
build complete plant networks. Figure 39.2 compares 
the HSE Foundation Fieldbus architecture against 
the ISO OSI reference model. 

Booking at Figures 39.1 and 39.2, it becomes evident that the 
Fieldbus Foundation has specified only one user application 
layer, for both the HI and HSE configurations. The HI and 
HSE Foundation Fieldbus user application layer is mainly 
based on Function Blocks, providing a consistent definition 
of inputs and outputs that allow seamless distribution and 
integration of functionality from various vendors [11]. 

HI Foundation FIELDBUS 

HI Foundation Fieldbus is made up by different layers (as 
shown in Figure 39.1), whose functionalities will be described 
in the following sub sections. 



FIG. 39.1 

HI Foundation Fieldbus vs. ISO OSI architecture. 


Application layer (AL) 


Presentation layer 


Session layer 


Transport layer 


Network layer 


Data link layer (DLL) 


Physical layer (PhL) 



Field device access 


TCP/UDP/IP 


IEEE 802.3 MAC and 
physical layers 


HSE system 
and network 
management 


FIG. 39.2 

HSE Foundation Fieldbus vs. ISO OSI architecture. 
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Physical Layer 

The HI Foundation Fieldbus Physical Layer has been con- 
ceived to receive messages from the communication stack 
in order to convert them into physical signals on the field- 
bus transmission medium and vice-versa [12]. Conversion 
tasks include the adding and removing of preambles, start 
delimiters, and end delimiters. The preamble is used by the 
receiver to synchronize its internal clock with the incoming 
fieldbus signal. The receiver uses the start delimiter to find 
the beginning of a fieldbus message. After finding the start 
delimiter, the receiver accepts data until the end delimiter 
is received. 

The Physical Layer is defined by approved standards 
issued by the IEC and ISA. In particular. Foundation 
Fieldbus HI Physical Layer is the 31.25 Kbauds version 
of IEC (type 1)/ISA Fieldbus [2,10], Signals (±10 mA on 
500 load) are encoded using the synchronous Manchester 
Biphase-L technique and can be conveyed on low cost 
twisted-pair cables. The signal is called “synchronous 
serial” because the clock information is embedded in the 
serial data stream. Data is combined with the clock signal 
while creating the fieldbus signal. The receiver of the field- 
bus signal interprets a positive transition in the middle of a 
bit time as a logical “0” and a negative transition as a logical 
“1.” Special codes are defined for the preamble, start delim- 
iter, and end delimiter. Special N+ and N- characters are 
used in the start delimiter and end delimiter. Note that the 
N+ and N- signals do not have a transition in the middle of 
a bit time. 

The transmitting device delivers ±10 mA at 31.25 kbit/s 
into a 50 Q equivalent load to create a 1.0 V peak-to-peak 
voltage modulated on top of the DC supply voltage. The DC 
supply voltage can range from 9 to 32 V. 

The 31.25 kbit/s fieldbus also supports Intrinsically Safe 
(IS) fieldbuses for bus powered devices. To accomplish this, 
an IS barrier is placed between the power supply in the safe 
area and the IS device in the hazardous area. In this case (IS 
applications), the allowed power supply voltage depends on 
the barrier rating. 

HI Foundation Fieldbus wiring is based on trunk cables 
featuring terminators installed at each end. HI Foundation 
Fieldbus allows for stubs or “spurs” located anywhere along 
the trunk, and connected to the trunk by junction box, as 
shown by Figure 39.3. A single device can be connected by 
each spur. Existence of spurs allows a 31.25 kbit/s device 
to operate on wiring previously used for 4-20 m A devices 
[13,14], 

More trunks can be connected in a Fieldbus link by means 
of repeaters. Up to five trunks (by means of four repeaters) 
can be interconnected. 

Spurs’ length varies from 1 m up to 120 m, depending on 
the number of devices connected to the fieldbus link. 

The maximum number of devices on a Fieldbus link is 
32; the actual number depends on factor such as the power 
consumption of each device, the type of cable, the use of 


Terminator 



FIG. 39.3 

Trunk, junction box, and spurs in HI Foundation Fieldbus. 

repeaters, etc. In particular, the maximum number of devices 
is usually 6 for intrinsically safe applications and power 
delivered through the bus, 12 for non-intrinsically safe appli- 
cations but power still delivered through the bus, 32 for non- 
intrinsically safe applications without any power delivered 
through the bus [15]. 

The total trunk length (including spurs) is 1900 m and the 
number of network addresses available for each link is 240. 

Data Link Layer 

HI Foundation Fieldbus DLL controls transmission of mes- 
sages onto the fieldbus. As already mentioned, Foundation 
Fieldbus fully adopted the IEC (Type 1)/ISA DLL statement: 
“Both paradigms, circulated token and scheduled access, 
were good but insufficient at the same time; they were com- 
plementary, not alternative, and a complete fieldbus solution 
needs the two together” [3,16,17], 

Thus, fieldbus needs a good mix of circulated token and 
scheduled access; well balanced to avoid losing bandwidth 
for the scheduled access when it isn’t really needed, but 
always giving priority to scheduled access over circulated 
token when a conflict arises. 

That is what the IEC (Type 1)/ISA DLL documents pro- 
pose, and Foundation Fieldbus made real: an overall sched- 
ule able to guarantee the needed data at the needed time, but 
also allowing gaps within which a circulated token mecha- 
nism can take place while complying with a defined maxi- 
mum rotation time. 

Such a philosophy clearly needs an arbitrator that uni- 
vocally imposes the transmission of a defined data at a 
defined time by a defined entity, when so required, but also 
guarantees a defined minimum amount of free time to each 
entity. This arbitrator is called Link Active Scheduler (LAS) 
within IEC (Type 1)/ISA and HI Foundation Fieldbus DLL 
[3,16,17]. Essentially, LAS performs the following: 
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• Access to the physical medium on a scheduled basis. 

• Circulation of the token only when no scheduled traf- 
fic is needed; token is passed for a limited amount of 
time that is always shorter than the interval left before 
the next scheduled traffic. 

• A policy for the management of the token, according 
to which, the token is returned to the LAS instead of 
passing it onto a new node so that the LAS, depending 
on the time left, can decide whether to actually pass 
the token once more or to resume link control to man- 
age the scheduled traffic. 

Specific needs of the token mechanism are as follows: 

• Giving enough contiguous token time to each node. 

• Guarantee of the most regular, as possible, token rota- 
tion time among all the nodes are granted by the token 
method of IEC (Type 1)/ISA and HI Foundation 
Fieldbus DLL. 

Other needs such as keeping the token cycle short enough 
and satisfying the occurrence of high priority events, are sub- 
stituted by the scheduled access method of IEC (Typel)/ISA 
and HI Foundation Fieldbus DLL. 

Device Types Two types of devices are defined in the DLL 
specification: Basic Device and Link Master. Link Master 
Devices are capable of becoming the LAS. Basic Devices do 
not have the capability to become the LAS. 

Scheduled Communication The way the LAS manages the 
centralized government is based on the following mecha- 
nism. The LAS has a list of transmitting times for all data 
buffers in all devices that need to be cyclically transmitted. 
When it is time for a device to send contents of a buffer, the 
LAS issues a Compel Data (CD) message to the device. 

Upon receipt of the CD, the device broadcasts or “pub- 
lishes” the data item (DT) in the buffer to all devices on the 
fieldbus. Any device configured to receive the data is called a 
“subscriber.” Figure 39.4 shows this access mechanism. 

Scheduled data transfers are typically used for the regu- 
lar, cyclic transfer of control loop data between devices on 
the fieldbus. 

Unscheduled Communication The federal autonomy of 
each node is given by a bandwidth distribution mechanism 
based on the use of a circulating token. In unused portions of 
the bandwidth (i.e., not occupied by the transmission of CDs), 
the LAS sends a Pass Token (PT ) to each node included in a 
particular list called “Live List” (described in the following 
section). Each token is associated with a maximum utiliza- 
tion interval, during which the receiving node can use the 
available bandwidth to transmit what it needs. On the expira- 
tion of the time interval or when the node completes its trans- 
missions, the token is returned to the LAS by using another 
frame called Return Token (RT). A Target Token Rotation 
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FIG. 39.4 

Centralized access mechanism. 

Time (TTRT) defines the interval time desired for each token 
rotation. The value to be assigned to this parameter is linked 
to the maximum admissible delay in the transmission of the 
asynchronous flow. Figure 39.5 shows the token circulation 
managed by the LAS. 

Live List Maintenance The list of all devices that are properly 
responding to the PT is called the “Live List.” New devices 
may be added to the fieldbus at any time. The LAS periodi- 
cally sends Probe Node (PN) messages to all the addresses 
not yet present in the “Live List.” If a new device appears 
at an address and receives the PN, it immediately returns a 
Probe Response (PR) message. When a device returns a PR, 
the LAS adds the device to the “Live List” and confirms its 
addition by sending the device a Node Activation message. 



I 

FIG. 39.5 

Token passing mechanism. 
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The LAS is required to probe at least one address after 
it has completed a cycle of sending PTs to all the devices in 
the “Live List.” The device will remain in the Live List as 
long as it responds properly to the PTs sent from the LAS. 
The LAS will remove a device from the “Live List,” if the 
device does not reply to the relevant PT for three successive 
tries. 

Whenever a device is added or removed from the Live 
List, the LAS broadcasts changes in the “Live List” to all 
devices; this allows each Link Master device to maintain a 
current copy of the “Live List” in order to be ready to become 
LAS if needed. 

Data Link Time Synchronization A DLL time synchroniza- 
tion mechanism is provided so that any node can request 
the LAS for a scheduled action to be executed at a defined 
“time” that represents the same absolute instant for all the 
nodes. 

The LAS periodically broadcasts a Time Distribution 
(TD) message on the fieldbus so that all devices have exactly 
the same data link time. This is important because sched- 
uled communications on the fieldbus and scheduled function 
block executions in the user application layer are based on 
timing derived from these messages. 

Link Active Scheduler Operation The algorithm used by the 
LAS is shown in Figure 39.6. 

LAS Redundancy IEC (Type 1)/ISA and HI Foundation 
Fieldbus DDL provides the possibility to have more than one 
potential LAS on each link as well as back-up procedures, 
which are essential for fieldbus availability. In particular, as a 
fieldbus may have multiple Link Masters, if the current LAS 
fails, one of the Link Masters will become the LAS and the 
operation of the fieldbus will continue. 


Application Layer 

The HI Foundation Fieldbus Application Layer includes 
two sub-layers: Fieldbus Access Sub-layer (FAS) and 
Fieldbus Message Specification (FMS) [18,19]. 

Fieldbus Access Sub-Layer FAS uses both the scheduled 
and unscheduled features of the DLL to provide services for 
the FMS [18]. 

The type of each FAS services is described by Virtual 
Communication Relationships (VCR). VCR defines the kind 
of the information (messages) exchanged between two appli- 
cations. Possible features of the VCR may be the number of 
receivers (one or many) for each transmitter, memory organi- 
zation (queue or buffer) used to store the messages to be sent/ 
received, and the DLL mechanism used to send the message 
(PT or CD). 

The types of VCR defined by Fieldbus Foundation are as 
follows: 

• Client/Server VCR Type. The Client/Server VCR Type 
is used for queued, unscheduled, user initiated, one to 
one communication between devices on the fieldbus. 
“Queued” means that messages are sent and received 
in the order submitted for transmission, according 
to their priority, without overwriting previous mes- 
sages. When a device receives a PT from the LAS, it 
may send a request message to another device on the 
fieldbus. The requester is called the “Client” and the 
device that received the request is called the “Server.” 
The “Server” sends the response when it receives a PT 
from the LAS. The Client/Server VCR Type is used for 
operator initiated requests such as set-point changes, 
access to and change of a tuning parameter, alarm 
acknowledgement, and device upload and download. 



FIG. 39.G 

LAS algorithm. CD, compel data; PN, probe node; TD, time distribution; PT, pass token. 
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• Report Distribution VCR Type. The Report Distribution 
VCR Type is used for queued, unscheduled, user ini- 
tiated, one-to-many communications. When a device, 
holding an event or a trend report to send, receives a PT 
from the LAS, it sends its message to a “group address” 
defined by its VCR. Devices that are configured to 
listen to that VCR will receive the report. The Report 
Distribution VCR Type is normally used by fieldbus 
devices to send alarm notifications to the operator 
consoles. 

• Publisher/Subscriber VCR Type. The Publisher/ 
Subscriber VCR Type is used for buffered, one-to- 
many communications. Buffered means that only the 
latest version of the data is maintained within the net- 
work. New data completely overwrites previous data. 
When a device receives CD, the device will “Publish” 
(broadcast) its message to all devices on the fieldbus. 
Devices that wish to receive the Published message 
are called “Subscribers.” CD may be scheduled in 
LAS, or it may be sent by Subscribers on an unsched- 
uled basis. An attribute of the VCR indicates which 
method is used. The Publisher/Subscriber VCR Type 
is normally used by the field devices for cyclic, sched- 
uled publishing of user application function block 
inputs and outputs. 

Fieldbus Message Specification FMS services allow user 
applications to exchange messages across the fieldbus using 
a standard set of message formats. FMS describes the com- 
munication services, message formats, and protocol behavior 
needed to build messages for the user application [19]. 

Data transmitted over the fieldbus are described by par- 
ticular objects maintained by an Object Dictionary (OD) and 
called “object descriptions.” Each object description is iden- 
tified by its “index” in OD; index 0, called the OD header, 
provides a description of the dictionary itself. 

A Virtual Field Device (VFD) is used to remotely 
view local device data described in the OD; the VFD 
are accessed using VCRs. A typical device will have at 
least two VFDs: the Network and System Management 
VFD and the user application VFD. The Network and 
System Management VFD provides access to the Network 
Management Information Base (NMIB) and to the System 
Management Information Base (SMIB). NMIB data include 
VCR, dynamic variables, statistics and LAS schedules (if 
the device is a Link Master); SMIB data include device tag 
and address information, and schedules for function block 
execution. The user application VFD is used to make the 
device functions visible to the fieldbus communication sys- 
tem; as it will be explained later, the functions of a fieldbus 
device are defined by the selection and interconnection of 
function blocks. 

FMS communication services provide a standard way for 
user applications to communicate over the fieldbus. Specific 
FMS communication services are defined for each object 
type. Table 39.1 summarizes the communication services 


available. Detailed description of each service is given 
in reference [19]. All of the FMS services use the Client/ 
Server VCR Type except as noted (see Notes (1) and (2) in 
Table 39.1). 

System Management 

Inside HI Foundation Fieldbus specification. System 
Management handles important system features [20] such as 
the following: 

• Function block scheduling. Function Blocks, on 
which a user application layer is built, must often be 
executed in a particular device at precisely defined 
intervals and in the proper sequence for correct con- 
trol system operation. System Management of the rel- 
evant device synchronizes execution of the Function 
Blocks to a common time clock shared by all devices. 
The execution of the Function Blocks is scheduled 
inside a so called “macrocycle,” which contains the 
precise sequence of Function Block execution for 
each device; a macrocyle is repeated once all the 
scheduled executions there contained are completed. 
According to the type of the device, we can have 
an LAS macrocycle and a device macrocycle. LAS 
macrocycle allows the System Management to syn- 
chronize execution of the Function Blocks across the 
entire fieldbus link; on the basis of the device mac- 
rocycle, instead, the System Management can syn- 
chronize execution of Function Blocks inside each 
device. Further information about Function Block 
Scheduling will be given in the next section. 

• Application clock distribution. This function allows 
publication of “the time of day” to all devices, includ- 
ing automatic switchover to a redundant time publisher. 
Foundation Fieldbus supports an application clock 
distribution function. The application clock is usu- 
ally set equal to the local time of day or to Universal 
Coordinated Time. System Management has a time 
publisher, which periodically sends an application 
clock synchronization message to all fieldbus devices. 
The data link scheduling time is sampled and sent with 
the application clock message so that the receiving 
devices can adjust their local application time. During 
the intervals between synchronization messages, 
application clock time is independently maintained 
within each device relying on its own internal clock. 

• Device address assignment. Fieldbus devices do 
not use jumpers or switches to configure addresses; 
instead, device addresses are set using System 
Management services. 

• Find tag service. For the convenience of host sys- 
tems and portable maintenance devices, System 
Management supports a service for finding devices or 
variables by a tag search. The “find tag query” message 
is broadcasted to all fieldbus devices. Upon receipt of 
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TABLE 39.1 

Set of Services in FMS 

Group 

Service 

Meaning 

Management and environment services 

Initiate 

Establish a communication 


Abort 

Abort a communication 


Reject 

Reject a nonvalid service 


Status 

Gives the status of a service 


Unsolicited status 

Send a non-requested status 


Identify 

Read a device specification (vendor, type, and version) 

OD services 

Get OD 

Read an OD 


Initiate put OD 

Start loading an OD 


Put OD 

Load an OD in a device 


Terminate put OD 

Stop loading an OD 

Variable access services 

Read 

Read a variable 


Write 

Update the value of a variable 


Information report 

Send data (1) 


Define variable list 

Define a variable list 


Delete variable list 

Delete a variable list 

Event services 

Event notification 

Notify an event (2) 


Acknowledge event notification 

Acknowledge an event 


Alter event condition monitoring 

Enable or disable an event 

Downloading/uploading services 

Request domain upload 

Request of domain upload 


Initiate upload sequence 

Initiate upload 


Upload segment 

Upload data 


Terminate upload sequence 

End upload 


Request domain download 

Request of domain download 


Initiate download sequence 

Initiate download 


Download segment 

Download data 


Terminate download sequence 

End download 


Generic initiate download sequence 

Open download 


Generic download segment 

Send data to device 


Generic terminate download 

Sequence stop download 

Program handling services 

Create program invocation 

Create a program object 


Delete program invocation 

Delete a program object 


Start 

Start a program 


Stop 

Stop a program 


Resume 

Resume execution of a program 


Reset 

Reset a program 


Kill 

Kill a program 


Notes: (1) Service can only use the Publisher/Subscriber or the Report Distribution VCR. 
(2) Service can only use the Report Distribution VCR. 


the message, each device searches its VFDs for the 
requested tag and returns complete path information 
(if the tag is found) including the network address, 
VFD number, VCR index, and OD index. Once the 
path is known, the host or maintenance device can 
access the data by its tag. 

All of the configuration information needed by System 
Management, such as the Function Block schedule, is 
described by object descriptions in the Network and System 
VFD. This VFD provides access to the SMIB and to the 
NMIB, as said before. 


Network Management 

HI Foundation Fieldbus Network Management mainly pro- 
vides for the configuration of the communication stack [21]. 


HSE Foundation FIELDBUS 

HSE enhances the HI applications of Foundation Fieldbus 
by providing a high-speed backbone, increased bandwidth, 
redundancy, and bridging capabilities for multiple proto- 
cols. As shown in Figure 39.2, the main feature of the HSE 
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FIG. 39.7 

HSE architecture. 

Foundation Fieldbus is the use of Internet Architecture for 
high-speed discrete control and, more generally, for intercon- 
necting several HI segments in order to achieve a plant wide 
fieldbus network. 

Figure 39.7 gives a more detailed description of the HSE 
Foundation Fieldbus architecture; this figure will be used 
later in this section for the description of the HSE specifi- 
cation. Before this, a brief overview of HSE Foundation 
Fieldbus general features will be given, with particular 
emphasis on the capability to interconnect different HI 
Foundation Fieldbus segments. 

General Features 

There are four basic HSE device categories (but several of 
them are typically combined into a single real device): LD, 
Ethernet Device (ED), Host Device (HD), and Gateway 
Device (GD). A LD connects HI networks to the HSE net- 
work. An ED may execute function blocks and may have 
some conventional I/O. A GD interfaces other network proto- 
cols. An HD is a non-HSE device capable of communicating 
with HSE devices; examples include configurators, operator 
workstations, and an OPC server. 

The network in Figure 39.8 shows a Host System 
operating on an HSE bus segment labeled segment (A). 
Communications to HI segments (B and C, as shown in the 
figure) are achieved by means of an Ethernet switch. The 
same switch is used to connect a second HSE segment (D) 
and a segment running a foreign protocol (segment E). 

Any of the devices connected to the switch may attempt 
communication to any other device and it is the function 
of the switch to provide the correct routing and to negoti- 
ate transmission without collisions. The connecting mecha- 
nism between HSE and HI segments is performed by a LD. 
Although a typical LD will serve multiple HI segments, for 


HSE segment A 



FIG. 39.8 

HI and HSE Foundation Fieldbus interconnection. 

simplicity, only one segment per LD is shown in Figure 39.8. 

The connection between HSE and a foreign protocol is made 

through a GD. 

The capabilities of the interconnections shown in Figure 

39.8 are as follows: 

• HSE Host/Hi segment. The HSE Host interacts with 
a standard HI device through an LD. In this situation, 
the HSE Host is able to configure, diagnose, and pub- 
lish and subscribe data to or from the HI device. 

• HSE Host/HSE segment. The HSE Host interacts with 
an HSE device and is able to configure, diagnose, and 
publish and subscribe data to or from the HSE device. 

• Hl/Hl segment. In this situation, the interaction is 
between two HI devices on two distinct HI bus seg- 
ments. The segments are connected to the Ethernet by 
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LDs. Communications between devices on two HI seg- 
ments are functionally equivalent to communications 
between two HI devices on the same bus segment. 
But it’s clear that real time communication between 
devices belonging to different HI segments cannot be 
guaranteed due to the lack of a unique scheduler of 
communication among different HI segments. 

• USE host/foreign protocol. This connection defines 
the relationship between a foreign device and the 
Foundation Fieldbus application environment. The 
connection is made by GD. The foreign device is seen 
as a publisher to an HSE resident subscriber; the HSE 
host can handle the data stream from the I/O gateway 
in the same manner as it treats the data streams from 
devices on Hl/HSE segments. 

Physical, Data Link, Network, and Transport Layers 

As shown by Figure 39.7, the standard IEEE 802.3 Physical 
and MAC layers have been adopted at the bottom of the 
HSE architecture [22,23]. HSE also makes use of the well- 
established TCP, UDP, and IP [24]. Standard HSE stack 
components are Distributed Host Configuration Protocol 
(DHCP), Simple Network Time Protocol (SNTP), and 
Simple Network Management Protocol (SNMP), which rely 
on TCP and UDP over IP and over the IEEE 802.3 MAC and 
Physical Layers. 

Messages sent on Ethernet are bounded by a series of 
data fields called frames. The combination of a message 
and frame is called an Ethernet packet. Typically, a packet 
encoded according to the TCP/IP protocols will be inserted 
in the message field of the Ethernet packet. 

Foundation Fieldbus uses a similar data structure where 
messages are bounded by addressing and other DTs. What 
corresponds to a packet in Ethernet is called a Protocol Data 
Unit (PDU) in Foundation Fieldbus. 

Let us consider a communication between two HI devices 
over an interposed HSE segment, as illustrated in Figure 39.8. 
The easiest method for LD might be, upon receiving a com- 
munication from an HI device, to simply insert the entire HI 
PDU into the message part of the TCP/IP packet. Then, LD 
on the destination HI segment, upon receiving the Ethernet 
packet, would merely strip away the Ethernet frame and send 
the HI PDU to the receiving HI bus segment. This technique 
is called tunneling, and is commonly used in mixed protocol 
networks. 

The solution developed by HSE Foundation Fieldbus is 
somewhat more complex, but more efficient than tunneling. 
HSE Foundation Fieldbus PDU is inserted into the data field 
of a TCP/IP message field. However, the Fieldbus address is 
encoded as a unique TCP/IP address, so the Fieldbus PDU 
address is used to fill the address field of the TCP/IP packet. 
The entire TCP/IP packet is then inserted into the message 
field of the Ethernet packet. Because of the HSE encoding 
scheme, networks having multiple LDs can locate and trans- 
fer messages to the correct destination much more quickly, 


with far less extraneous bus traffic, as opposed to tunneling. 
Perhaps even more important, every HI device (and every 
HSE device for that matter) has a unique TCP/IP address 
and can be directly accessed over standard IT and Internet 
networks. 

Application Layer 

Existing Fieldbus specifications, which have been widely 
tested in HI applications and had already been maintained 
by the Fieldbus Foundation, have been used in the HSE 
standard too, wherever applicable. These include FMS and 
System Management (SM). 

A new technology has been developed and tested to pro- 
vide a complete high-speed communications and control 
solution; the new technology is based on the Field Device 
Access Agent (FDA Agent), shown in Figure 39.7 [25]. 

The FDA Agent allows SM and FMS services used by the 
HI devices to be conveyed over the Ethernet using standard 
UDP and TCP. This allows HSE devices to communicate 
with HI devices that are connected via an LD. 

The FDA Agent is also used by the local Function Blocks 
in a HSE device. Thus, the FDA Agent enables remote appli- 
cations to access HSE devices and/or HI devices through a 
common interface. 

System Management 

The following aspects of management are supported in the 
HSE System Management Layer [26]: 

• Each device has a unique and permanent identity, and 
a system-specific configured name. 

• Devices maintain version control information. 

• Devices respond to requests aiming to locate objects, 
including the device itself. 

• Time is distributed to all devices on the network. 

• Function block schedules are used to execute function 
blocks inside a device. 

• Devices are added and removed from the network 
without affecting other devices on the network. 

Network Management 

HSE Network Management allows HSE host systems to per- 
form management operations over the HSE network [27]. 
The following capabilities are provided by the network 
management: 

• Configuring the HI Bridge, which performs data for- 
warding and republishing between HI interfaces (see 
Figure 39.7). 

• Loading the HSE Session List, or single entries in this 
list, called endpoints. An HSE Session Endpoint rep- 
resents a logical communication channel between two 
or more HSE devices. 
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• Loading the HSE VCR List, or single entries in this 
list. An HSE VCR is a communication relationship 
used for accessing VFDs across HSE. 

• Performance Monitoring for Session Endpoints, HSE 
VCRs, and the HI Bridge. 

• Fault Detection Monitoring. 

Redundancy 

HSE Foundation Fieldbus is used at the host-level of the 
control system; the host-level network ties the whole system 
together linking the various subsystems to the host. Thus, 
the visibility of hundreds and perhaps thousands of loops 
depends on the host-level network, as does any intra-area 
control loops. A complete failure could result in heavy losses. 
High availability for the host-level network is therefore para- 
mount. HSE Foundation Fieldbus adopts media and device 
redundancy to reach this aim. 

Special integrity-checking diagnostics and redundancy 
management part of the HSE protocol in each device enables 
the use of two completely independent networks, redundant 
communication ports, and also redundant device pairs. 

All parts of the network have redundancy, including the 
hubs (i.e., two independent networks ensuring that commu- 
nication can continue even if one network fails). This means 
that the network can sustain multiple faults but still continue 
to function. All redundant ED pairs and the workstations are 
connected to both the Ethernet buses. 

A device may have redundant communication ports, and 
in this case the two ports are named “A” and “B.” In case 
of fault, the switchover is totally bumpless and transparent. 
Every communication port has a unique IP address; the IP 
address does not change when the communication ports 
switch. 

True device redundancy is implemented using two identi- 
cal devices, one primary and one secondary; when a primary 
device fails, the secondary takes over the role of the primary. 
Primary and secondary devices need to have identical con- 
figuration in order to allow for a quick switchover in case of 
failure. The HSE protocol specifies how these devices com- 
municate with others and how the communication is switched 
over. However, HSE does not specify how the functionality is 
switched or how device configuration and data are synchro- 
nized. The control application sees either the primary or the 
secondary ED depending on which one is active, whereas the 
system diagnostics sees both. Thus, the diagnostics insures 
that even the inactive devices are fully functional and ready 
to take over at any moment. 

A wide diagnostic coverage is an integral part of the 
HSE protocol going far beyond mere hardware duplication. 
Every HSE device and HSE LD contains an HSE Local Area 
Network (LAN) Redundancy Entity (HSE LRE), shown in 
Figure 39.7. The HSE LRE independently keeps track of the 
status of the networks and all the devices on it; it periodi- 
cally sends and receives Redundancy Diagnostic Messages, 
which represent its view of the network with each other. Each 


HSE device or LD uses the diagnostic messages to maintain 
a Network Status Table (NST), which is used for fault detec- 
tion and transmission port selection. In this way, every device 
has a complete picture of the network and knows the health 
of the primary and secondary, as well as communication port 
A and B, of every other device on the network in order to 
intelligently select which network, device and port to com- 
municate with. 

Because the redundancy management is distributed 
to each device, no centralized “redundancy manager” is 
required [28]. 

HI AND HSE Foundation FIELDBUS USER APPLICATION LAYER 

As mentioned earlier, the Fieldbus Foundation has defined a 
standard user application layer based on “Blocks.” Blocks are 
representations of different types of application functions. 
The types of blocks used in a user application are Resource, 
Transducer, and Function. Devices are configured by using 
Resource Blocks and Transducer Blocks. The control strat- 
egy is built by using Function Blocks [11] instead. 

Resource Block 

The Resource Block describes characteristics of the fieldbus 
device such as the device’s name, manufacturer, and serial 
number. There is only one Resource Block in a device. 

Function Block 

Function Block (FB) provides the control system behavior. 
The input and output parameters of Function Blocks, running 
in different devices, can be linked over the fieldbus. The exe- 
cution of each Function Block is precisely scheduled. There 
can be many function blocks in a single user application. The 
Fieldbus Foundation has defined sets of standard Function 
Blocks. Ten standard Function Blocks for basic control are 
defined [11] by “part 2” specifications. These blocks are sum- 
marized in Table 39.2. Other, more complex, standard func- 
tion blocks are defined [11] by “part 3 and 4” specifications. 


TABLE 39.2 

Basic Function Blocks 


Function Block Name 

Symbol Name 

Analog input 

AI 

Analog output 

AO 

Bias/gain 

BG 

Control selector 

CS 

Discrete input 

DI 

Discrete output 

DO 

Manual loader 

ML 

Proportional/derivative 

PD 

Proportional/integral/derivative 

PID 

Ratio 

RA 
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FIG. 39.9 

Example of a complete control loop using function blocks in 
Foundation Fieldbus devices. 

The Flexible Function Block (FFB) is defined [11] by 
“part 5.” An FFB is a user defined block. FFB allows a manu- 
facturer or user to define block parameters and algorithms to 
suit an application that interoperates with standard function 
blocks and host systems. 

Function blocks can be built into fieldbus devices as 
required in order to achieve the desired device functionality. 
For example, a simple temperature transmitter may contain an 
AI function block. A control valve might contain a PID func- 
tion block as well as the expected AO block. Thus, as shown 
by Figure 39.9, a complete control loop can be built, using only 
a simple transmitter (Device 1) and a control valve (Device 2). 

Transducer Blocks 

Like the Resource Block, the Transducer Block is used to 
configure devices. Transducer Blocks decouple Function 
Blocks from the local input/output functionalities required 
in order to read sensors or to command actuator’s output. 
They contain information such as calibration date and sensor 
type [29]. 

Supporting Objects 

The user application provides for the following additional 
objects: 

• Link Objects define the links between Function Block 
inputs and outputs internal to the device and across 
the fieldbus network. 

• Trend Objects allow local trending of function block 
parameters for access by hosts or other devices. 

• Alert Objects allow reporting of alarms and events on 
the fieldbus. 

• Multi-Variable Container (MVC) Object serves to 
“encapsulate” multiple Function Block parameters in 
order to optimize communications for Publishing- 
Subscriber and Report Distribution transactions. 

• View Objects are predefined groupings of block 
parameter sets that can be displayed by the human/ 
machine interface. The function block specification 
defines four views for each type of block. 


Function Block Scheduling 

A very important concept to understand is that execution of 
function blocks may be scheduled in each device, including 
the LAS if present. Such a schedule must be reproduced and 
repeated in each device in a periodic fashion; for this reason, 
a macrocyle is defined in each device, containing a particular 
sequence of function blocks execution. The content of each 
macrocyle is repeated in each device forever, until a modi- 
fication in the schedule occurs. A macrocycle contains the 
instants at which a function block must be executed, starting 
from an absolute start time. 

As an example, consider the function blocks presented in 
Figure 39.9 (AI, PID, and AO), and assume that the following 
scheduling has been realized: 

• AI Function Block in Device 1 is executed at offset 0 

(from an absolute start time). 

• Communication of AI occurs at offset 20. 

• PID Function Block in Device 2 is executed at offset 30. 

• AO in Device 2 is executed at offset 50. 

Considering HI system, Figure 39.10 shows the macrocyle 
in each device, including LAS, which takes into account the 
previous scheduling. 

According to these macrocycles, System Management 
in Device 1 will cause the AI function block to execute at 
offset 0. At offset 20, the LAS will issue a CD to the AI 
function block buffer in the transmitter and data in the buf- 
fer will be published on the fieldbus. At offset 30, System 
Management in the valve will cause the PID function block 
to execute followed by execution of the AO function block 
at offset 50. The pattern exactly repeats itself assuring 
the integrity of the control loop dynamics. Note that dur- 
ing the function block execution, the LAS is sending the 
PT message to all devices so that they can transmit their 
unscheduled messages such as alarm notifications or opera- 
tor setpoint changes. For this example, the only time that the 
fieldbus cannot be used for unscheduled messages is from 
offset 20 to offset 30, when the AI function block data is 
being published on the fieldbus. 

On the HSE fieldbus, the function blocks execute accord- 
ing to the Device 1 and Device 2 macrocycles, shown in 
Figure 39.10; but the lack of LAS implies that the communi- 
cation of AI occurs without any schedule on the bus. 


WIRELESS SOLUTIONS FOR Foundation FIELDBUS 

Currently, a large amount of the total cost of a manufactur- 
ing plant over its lifetime is spent on installation, setup, and 
reconfiguration. If a plant is subject to changes in its process 
flow or changes due to the introduction or replacements of 
equipment, then the downtime and lifetime costs rise con- 
siderably [30]. 
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FIG. 39.10 

Function block scheduling using macrocyte executions. 


One of the main obstacles to fast reconfiguration is the 
inflexible wired communication infrastructure; this prob- 
lem can be largely eased by the use of wireless technologies. 
With wireless technologies, not only the installation costs 
are much lower, but also the true self-reconfiguration of a 
system without any rewiring becomes possible as ever did 
before [30,31]. Together with other technologies like Service 
Oriented Architectures, web services, and the use of agent 
technology, wireless at the physical level play an important 
role toward flexible and self-reconfiguring systems. 

There are several other motivations for using wireless in 
automation. Sometimes the use of wireless is mandatory; this 
is the case when the mobility of some devices is required, 
as for instance, in Automatic Guided Vehicles. It is also the 
case for applications, where chemicals, vibrations, or moving 
parts could damage cabling. In these cases wireless commu- 
nications are almost a must for the application. 

In some cases there is not an absolute need for wireless 
but the costs of wiring are prohibitive, as it would be the case 
of reading a small number of sensors in a large geographical 
area. In these cases, wireless is not a must but it presents eco- 
nomical advantages. To a certain extent, these are somewhat 
the same economical advantages that, in the past, were used 
to justify the use of fieldbus instead of point-to-point con- 
nections, but now with a more drastic approach (zero cabling 
costs). 

In spite of the economical and structural advantages, 
some skepticism exists toward the use of wireless in industrial 


plants, especially in real-time systems. Some of the handicaps 
related to the wireless transmission are relevant to: Path loss 
(depending on the type of antennas used, the signal strength 
decreases with distance exponentially), Multipath fading (the 
wireless communications are prone to reflection and diffrac- 
tion), Security (wireless waves are easily detected by any 
receptor in the range for illicit eavesdropping), and Safety 
(in spite of strict regulations about electromagnetic interfer- 
ence, in an industrial environment, strong motors, electrical 
discharges usually affect wireless communications too). 

Wireless Standards: ISA100 vs. WirelessHART 

The communication system in a plant or factory can gen- 
erally be divided into several levels. At the top there is the 
Business Information Network, which carries information 
important to business functions like accounts receivable, plus 
production related matters such as Manufacturing Resource 
Planning and the like. Below there is the Control-Level 
Network, which connects major components of the automa- 
tion system like controllers, operator interfaces, I/O racks, 
and so on. At the bottom, there is the Field Device Network, 
which connects sensors and actuators, including valve posi- 
tion indicators, back to the control system. 

At the field device level, the current market of wireless 
communication systems offers a great choice, but most of 
them are proprietary, not compliant to open standards and 
not able to guarantee interoperability. 
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Since the past few years, two standards have been defined: 
the ISA 100.11a and the WirelessHART. 

ISA100. 11a, “Wireless Systems for Industrial Automation: 
Process Control and Related Applications,” is an open wire- 
less standard developed by the ISA SP-100 committee, start- 
ing from 2005 [32]. Definition of ISAlOO.lla represents a 
very important milestone in the use of wireless technology 
inside industrial environment. The standard defines all the 
specifications relevant to the use of wireless tools for the 
application at field level, including important issues linked 
to security and to the management of devices. ISAlOO.lla 
runs at 2.4 GHz, adds channel-to-channel frequency hopping 
to the regular DSSS, and uses a mesh topology and time divi- 
sion multiplexing (each node is assigned its own time slot 
and sleeps the rest of the time). It can be used for class 1 
(non-critical) to class 5 applications. Officially adopted in 
September 2009, advantages of ISAlOO.lla are the ability 
to work with multiple network protocols (HART, Profibus, 
Modbus, Foundation Fieldbus, etc.), reliability, and security. 

ISA is not the only institution involved in the definition 
of a standard wireless communication system for industrial 
applications. HART Communication Foundation (HCF) 
[33] is an organization made up by the producers and end 
users of wireless devices, which include ABB, Emerson, 
Honeywell, and Siemens. HART developed an open stan- 
dard, the HART 7.0, which extends the HART protocol 
with wireless features known as WirelessHART; also this 
standard has been conceived for wireless communication at 
field level. WirelessHART runs at 2.4 GHz, using O-QPSK 
modulation at a data rate of 250 kbps and, like ISA 100.11a, 
uses frequency hopping (channel-to-channel) to increase 
resistance to interference. It uses a mesh topology (every 
node is a router) and time division multiplexing, with field 
devices that connect to process or plant equipment, gateways 
that provide communication between the field devices and 
host system applications, and network manager software. 
The system supports adapters that allow existing HART field 
devices to be integrated into a WirelessHART network and 
short-range handhelds for direct communication with indi- 
vidual field devices. WirelessHART is backward compatible 
to core HART technology and Device Description Language 
(DDL). WirelessH ART’s advantages include low power con- 
sumption per node, reliable communications, resistance to 
interference, and the ability to handle up to 1000 nodes. Its 
weaknesses include reduced throughput for busty traffic, the 
existence of a single point of failure unless redundant gate- 
ways are used, and higher cost than other systems. In March 
2010, the IEC has approved the WirelessHART specification 
as a full international standard (IEC 62591 Ed. 1.0) [34], 

As said, the physical layer of the two standards is identi- 
cal; for this reason ISA 100.11a and WirelessHART are built 
using the same chip. They operate at the same frequencies 
and use the frequencies in approximately the same way. 
However because of differences in the upper-layer protocols, 
they are not compatible; the two standards involve the same 
kind of applications but they are basically incompatible. 


Since both ISA 100.11a and WirelessHART appeared, 
end users were confused by their presence, for several rea- 
sons. One of the main reasons is the difficulty to understand 
the need for two open standards for the same field device 
level. A more important question is how it was possible that 
some companies involved in the development of HART 7.0 
were also involved in the definition of ISAlOO.lla; in par- 
ticular, end users wondered how these companies were not 
able to cooperate with each other to produce only one stan- 
dard able to include ISA 100 and HART. Finally, they did not 
understand why the ISA 100 committee did not produce any 
effort to integrate the WirelessHART, using the same defini- 
tion of ISA 100.11a. Last question was about the real need of 
the ISA 100, if the WirelessHART was available since many 
years before. 

All these questions had finally an answer at the 2007 
ISA Expo in Houston, where ISA 100 committee defined 
the approach aimed to integrate its standard with the 
WirelessHART. The solution adopted foresees the defini- 
tion of the special working group ISA100.12, which has the 
task to make the two standards converge. Until now, the joint 
committee was able to define the specification of a network 
interface gateway (dual-mode) which is the same for both 
the ISA 100.11a and WirelessHART networks; the defini- 
tion of this dual-mode gateway has been introduced into the 
ISA 100.11a specification. Thanks to this solution, a DCS or 
whatever other host system is able to access the information 
produced by a field device attached both in a WirelessHART 
and in an ISA 100.11a network, basically in the same way, by 
the dual-mode gateway. In this way, the wireless networks 
may be different and non-interoperable, but they could co- 
exist and communicate through this common dual-mode 
gateway. 

Wireless Foundation Fieldbus 

At this moment, it’s not clear how and when the ISA 100.11a 
and WirelessHART standards will be fully integrated; but, 
strictly considering Foundation Fieldbus, it’s very impor- 
tant to point out that this communication system is already 
able to build its communication protocol on top of either ISA 
100.11a or WirelessHART. 

In fact, ISA 100.11a presents an Application sub-layer, 
able to provide for capabilities and services to enable an open 
interoperable ISAlOO.lla application environment. A tunneling 
protocol allows the ISAlOO.lla network to carry existing proto- 
cols such as Foundation Fieldbus. Object-oriented modeling 
concepts support both ISAlOO.lla native and non-ISAlOO.lla 
native (legacy) protocol tunneling applications. 

About the integration of Foundation Fieldbus and 
WirelessHART, during these last years, WirelessHART 
received so much consensus that a Wireless Cooperation 
Team (made up by Fieldbus Foundation, HCF and Profibus 
Nutzer Organization e.V.-PNO) started an activity aimed to 
define the specification of a common wireless gateway inter- 
face for WirelessHART, Foundation Fieldbus, Profibus, 


© 2012 by Bela Liptak 



39 

and Profinet. The planned approach is to use efficient transla- 
tions between protocols rather than tunneling, and to perform 
the translations in the gateway, where electrical and compu- 
tational power is abundant. 

OPEN SYSTEMS IMPLEMENTATION 

One of the main features of Foundation Fieldbus (in both 
HI and HSE configurations) is the availability to build open 
communication systems. It is clear that, this represents a key 
issue in a communication system, as building up a perfect 
communication stack between two devices is completely use- 
less if those two devices are not able to understand the mean- 
ing of each other’s data, nor each other’s behavior. 

Implementation of open systems in Foundation 
Fieldbus has been achieved from the beginning through the 
use of Function Blocks and the adoption of a standard way to 
represent them (the DDL). 

Very recently a strong effort has been put by Fieldbus 
Foundation to integrate DDL technology with that known 
as FDT/DTM (Field Device Tool/ Device Type Manager). 
In particular, starting from 2003, Fieldbus Foundation con- 
tributes to the FDI, the Field Device Integration initiative, 
as part of an industry effort to integrate Electronic Device 
Description Language (EDDL) and FDT. 

In the following subsections a detailed description of 
both DDL and FDT/DTM will be given; finally the FDI ini- 
tiative will be pointed out. 

Electronic Device Description Language 

An EDDL is defined by the international standard IEC 
61804-3 [35,36]. EDDL is endorsed by four major founda- 
tions: Fieldbus Foundation, HCF, Profibus Nutzerorganisation 
e.V (PNO), and the OPC Foundation. 

ISA SP104 is the standards committee that is working 
to adopt the generic DDL specified by IEC 61804 for device 
integration; the committee has voted in October 2006 to 
adopt the IEC 61804 standard as an ANSI/ISA standard and 
is committed to provide information that will help users and 
integrators to support a wide gamut of intelligent devices by 
the use of EDDL interface. Furthermore, a joint Fieldbus 
Foundation, Profibus and HCF project started few years 
ago to specify visualization and data storage management 
extensions. 

The IEC 61804-3 standard specifies EDDL as a generic 
language for describing the properties of automation system 
components, such as device parameters and their dependen- 
cies, device functions (e.g., simulation mode, calibration), 
graphical representations (e.g., menus), interactions with 
control devices, graphical representations, and persistent 
data store. EDDL technology was designed to avoid the need 
for special, proprietary, and operating system-specific host 
application files. It allows a host system to both configure and 
monitor devices on-line. 
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An EDD (Electronic Data Description) is a computer 
readable file written in EDDL that describes the data in a field 
device; it is the file that the Host application reads in order to 
learn how to retrieve information from the field device. EDD 
is a clear and unambiguous structured text description that 
precisely describes field device data to host systems. EDD is 
independent from the operating system, DCS platforms and 
communication and interface paths. It allows interoperability 
as devices from different suppliers can interoperate with a 
single Host and the same device can interoperate with differ- 
ent Hosts. There is no executable code with EDD, which may 
have an effect to the stability of the Operating System; EDD 
is interpreted and therefore encapsulated. No impact of one 
EDD to others and easy update and device additions during 
operation are guaranteed. 

An EDD contains the following information about the 
parameters of a device: attributes (like coding, name, engi- 
neering unit, write protection, how to display, etc.), the 
arrangement of the parameters in a menu structure, names 
of menus and submenus, information about the relation of 
parameters to others, information about help texts and help 
procedures, information about necessary operating inter- 
actions (e.g., calibration), also called methods and infor- 
mation about visualization tools (i.e., charts and graphs). 
EDD can also describe communication features: commu- 
nication orders, sorting of parameters, bit positioning and 
bit length of parameters, sorting of communication orders, 
read and write timeouts, and error handling including user 
messages. 

As said before, two EDDL extensions are recently avail- 
able; they are the EDDL Visualization and the Persistent 
Data Storage extensions. They allow EDD developers to 
describe in a powerful way both screen layout and data stor- 
age in a host. 

FieldBus Foundation EDDL Products 

The IEC 61804 EDDL includes the DDL, used as an underly- 
ing technology by Foundation Fieldbus, to achieve interop- 
erability [37]. 

Device Description (DD) technology is used in addition 
to standard function block parameter and behavior defini- 
tions. A DD file, written in the DDL, provides an extended 
description of each object in the VFD; it provides informa- 
tion needed for a control system or host to understand the 
meaning of the data in the VFD including the human inter- 
face for functions such as calibration and diagnostics. Thus, 
the DD can be thought of as a “driver” for the device; any 
control system or host can operate with the device if it has 
the device’s DD. 

DD file is used together with a Capability File (CF) to 
fully describe a device. The CF describes the functions and 
the capabilities of the device; it tells the host what resources 
the device has in terms of function blocks and VCRs etc. This 
allows the host to configure the device even if not connected 
to it. The host can ensure that only functions supported by 
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the device are allocated to it, and that other resources are not 
exceeded. 

On account of what said, a device is always supplied with 
DD and CFs. 

Device Description Services On the host side, library func- 
tions called Device Description Services (DDS) are used to 
read the device descriptions, but they cannot read operational 
values [38]. The operational values are read from the fieldbus 
device over the fieldbus using FMS communication services. 
New devices are added to the fieldbus by simply connect- 
ing the device to the fieldbus wire and providing the control 
system or host with the DD for the new device. DDS technol- 
ogy allows operation of devices from different suppliers on 
the same fieldbus with only one version of the host human 
interface program. 

Device Description Hierarchy The Fieldbus Foundation has 
defined a hierarchy of DD to make it easier to build devices 
and perform system configuration. The first level in the hier- 
archy is referred to as Universal Parameters, which consist of 
common attributes such as Tags, Revisions, Modes, etc.; all 
blocks must include the Universal Parameters. The next level 
in the hierarchy is Function Block Parameters; at this level, 
parameters are defined for the standard Function Blocks and 
Resource Blocks. The third level is called Transducer Block 
Parameters; at this level, parameters are defined for the stan- 
dard Transducer Blocks. In some cases, the transducer block 
specification may add parameters to the standard Resource 
Block. These first three layers are the standard Fieldbus 
Foundation DDs. The fourth level of the hierarchy is called 
Manufacturer Specific Parameters; at this level, each manu- 
facturer is free to add additional parameters to the Function 
Block Parameters and Transducer Block Parameters. 

Device Description Interoperability Test Before Fieldbus 
Foundation registers a DD file, the file undergoes a series of 
tests using FF’s Interoperability Test Kit [39]. The first test 
loads the DD binary into a test system to validate correct 
identification information. Next, the file undergoes multiple 
test cases to ensure the DD matches the device and follows 
protocol rules for maintaining interoperability between host 
and device. Finally, FF logs the DD hie information, includ- 
ing name, date, size, and the 32 bit cyclic redundancy check- 
sum value. 

Field Device Tool/Device Type Manager 

About 5 years ago, FDT technology arrived; it has been 
defined and is supported by the FDT Group that is a nonprofit 
organization [40]. FDT has been defined by the IEC 62453 
standard [41]. 

The FDT standard is supported by more than 70 indus- 
trial and process automation organizations, and it is esti- 
mated that more than one million FDT-based products have 


been shipped since the inception of the standard. Installations 
range from small automation to some of the largest process 
installations in the world. 

The FDT standard currently supports more than 14 indus- 
try network standards, including Foundation Fieldbus, and 
more are in the works. Due to the structure of the open FDT 
standard, it is possible for anyone to add new network stan- 
dards to the architecture. Some companies have used this 
capability to support legacy and proprietary networks in 
the same frame application that supports industry standard 
networks. 

While attaining the IEC 62453 status was a major 
milestone for the FDT Group, efforts of the Standards and 
Associations working group are not yet over. The IEC stan- 
dard is in the process of being accepted as an ISA standard in 
the United States. This work was initiated last year and it is 
expected to be completed near the end of 2010. 

More recently, the FDT Group has initiated the process to 
have the FDT standard adopted as a Chinese standard. This 
work will be completed in 2011. 

Meanwhile, the FDT Group Architecture and 
Specification team is busy completing a major update to the 
current FDT standard. This body of work, commonly known 
as FDT 2.0, is expected to receive membership approval in 
late 2010 or early 2011. While many new features will be 
incorporated based on industry requirements, the FDT 
Group is working to ensure that the standard becomes easier 
for manufacturers and end users to adopt and deploy. 

Basically, FDT ensures interoperability of all fieldbus 
and network standards, the ability for the end user to pick the 
best in class devices regardless of manufacturer, and frees the 
manufacturers to competitively differentiate the configura- 
tion, operation, diagnostics, and maintenance of their device 
with a single driver. 

According to the standard, the DTM is the driver supplied 
by the manufacturer of the device that supports the configu- 
ration, operation, diagnostics, maintenance, and calibration 
of the device. A single DTM may support an entire family or 
class of devices offered by that manufacturer. The DTM can 
be supplied with the device, in a library of all devices offered 
by the manufacturer, or downloaded via the internet. 

There are two types of DTMs. The most common DTMs 
support end devices such as pressure or temperature trans- 
mitters, IO blocks, or valve positioners. The second type, 
called a COM (communications) DTM, is provided by the 
manufacturers of the network infrastructure components 
such as GDs, SIL barriers, and network power supplies. 

The COM DTM has brought a complete revolution to net- 
work management. Some COM DTMs now can monitor the 
health of the network and its infrastructure such as barriers, 
network power supplies, and terminators. Gone are the days 
of having to haul out network analyzers to see if the problem 
could be related to the network infrastructure. The pulled ter- 
minator, the forklift-damaged cable, the colliding packets, the 
network reaching bandwidth limits, and the failing redundant 
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supply can be proactively detected and reported through the 
diagnostics of the COM DTM. 

Traditionally, a moderately complex network requires 
direct access to the network or scanner to which the device is 
connected, in order to use standard configuration and main- 
tenance tools. The FDT standard changes this paradigm by 
providing access to any device from anywhere on the net- 
work. This is made possible by a feature called “nested com- 
munications” through the features of the COM DTMs that 
are used to make the hop from one network to the next. 

The DTM is installed in a host application, which is 
called the Frame. A FDT Frame is a higher level software 
application, such as a DCS, a PLC programming tool, or a 
maintenance management system, which is compliant with 
the FDT standard and needs access to the intelligent devices 
on the fieldbuses or networks associated with the application. 
The Frame gains access to the device intelligence and func- 
tionality by installing the appropriate DTMs into the topol- 
ogy tree of the application. 

EDDL vs. FDT: FDI 

EDDL and FDT are different technologies both aimed at 
providing easy plug-and-play access to information in smart 
field devices. For the past few years, many have seen EDDL 
and FDT as competing technologies. Yet a growing number 
of vendors have declared neutrality on the matter of whether 
they prefer EDDL or FDT. Automation vendors are begin- 
ning to view the two technologies as complementary. 

In a growing number of cases, plants are using a combina- 
tion of EDDL and FDT. There are at least two cases for this. 
First, the basic integration is done with EDDL, but additional 
advanced diagnosis functionality is provided by the device 
vendor at FDT/DTM, which runs in a FDT frame application. 
In the second case, several device vendors do not provide 
DTMs for their simple to medium-complex devices; in this 
instance, those EDDs are run in an EDD interpreter DTM. 

It’s clear that integration of the two technologies may 
cause some problems, which must be carefully avoided. On 
the basis of the specifications on which the two systems are 
designed, there is a potential for conflict. For example, if the 
FF LAS is created using DD or EDDL information, the con- 
trol system configuration tool knows all this information and 
should be the only means to change it. A DTM running via a 
co-resident FDT tool could inadvertently change some of that 
information without the system’s knowledge. 

Because both EDDL and FDT have their adherents, and 
both are clearly here for the long run, the industry has started 
an initiative to integrate the two technologies. Many end 
users were not comfortable with these two technologies in 
tandem, and preferred to realize a full integration. 

As part of an industry effort to integrate EDDL and FDT, 
a number of groups created FDI, the Field Device Integration 
initiative. The main aim of the work carried on by the FDI 
was to combine the best features of EDDL and the FDT 


standard. The Field Device Integration, or FDI, is a project 
among all the major suppliers to bring together EDDL and 
FDT technology into a single technology that will be com- 
patible with both technologies. 

The FDI initiative began in 2003. Initially it was sup- 
ported by the three organizations: Fieldbus Foundation, 
HCF, and Profibus. Part of the charter for the FDI was the 
need for a unified method to traverse the software layer of 
the control system, so these organizations invited the OPC 
Foundation to aid them in supporting the integration. The 
FDT Group was also invited to join. Other companies that 
joined the FDI project include the following: ABB, Emerson 
Process Management, Endress+Hauser, Honeywell, Invensys, 
Rockwell Automation, Siemens, and Yokogawa. 

One piece of glue that represents a factor in integrat- 
ing EDDL and FDT is OPC [42]; technology from the OPC 
Foundation is a key element in integrating EDDL and FDT. 
OPC UA (Unified Architecture) is a way to put some stan- 
dards around the process of getting data from devices. 

The FDI team performed a complete inventory of use 
case analysis and designed a draft architecture concept and 
a draft functional specification. The architecture is a cli- 
ent/server structure based on OPC UA. The Field Device 
Integration is realized by a “Device Package” provided by 
the device supplier containing EDDL components and an 
optional programmed component for programmed user 
interfaces. 

The definition of the integration is carried on taking into 
account the following main requirements to be fulfilled; the 
solution must be platform and operating system indepen- 
dent, must provide access to the full capability of the field 
device, must support several communication systems among 
Foundation Fieldbus, HART, and Profibus, must be adopt- 
able to support other fieldbus communication technologies, 
and must provide backward compatibility with existing EDD 
and DTM based technologies. 

The current phase of the project includes development 
of the detailed specifications followed by validation of the 
specifications by each of the member organizations. Details 
of the exact FDI architecture and associated device interface 
will be unveiled with the release of the final functional speci- 
fication, currently planned within 2010. 

Foundation FIELDBUS SOFTWARE SUPPORT 

The following tools are available inside Foundation 
Fieldbus to support many important operations: 

• Engineering tool. An engineering tool can help to 
build a control strategy completely independent of the 
device to be eventually used. Through an engineer- 
ing tool, the process engineer can build the control 
strategy and later the instrument engineer can assign 
the blocks to devices. For example, we can build a 
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basic P1D control template, using the standard FF P1D 
Function Block. When the block is later assigned to a 
device, the engineering tool confirms with the CF of 
the device that the standard PID is supported. 

• Function block schedule building tool. A schedule 
building tool is used to generate function block sched- 
ules, including those relevant to LAS. The schedules 
contain the start time offset from the beginning of the 
“absolute link schedule start time,” as explained in the 
previous sections. 

• Configuration tool. Every fieldbus device must have 
a unique network address and physical device tag for 
the fieldbus to operate properly. To avoid the need 
for address switches on the instruments, assignment 
of network addresses can be performed by configu- 
ration tools using System Management services. The 
sequence for assigning a network address to a new 
device is as follows: 

a. An unconfigured device will join the network at 
one of the four special temporary default addresses. 

b. The configuration tool will assign a physical device 
tag to the new device using System Management 
services. 

c. The configuration tool will choose an unused per- 
manent address and assign it to the device using 
System Management services. 

d. The sequence is repeated for all devices that enter 
the network at a default address. 

• Conformance test tools. The HI and HSE 
Conformance Test Kits are complete packages that 
allow the user to ensure that a manufacturer’s stack 
conforms to the Fieldbus Foundation’s official HI 
and HSE registration testing. This product will verify 
the correct communication behavior of an Hl/HSE 
device as defined in the Hl/HSE specifications. It is 
an excellent tool for troubleshooting and debugging 
the respective devices. 

• Interoperability test tools. The HI and HSE 
Interoperability Test Kits verify the functionality of 
a device with the Foundation Fieldbus’ Function 
Block Specifications. These test kits include all hard- 
ware and software required to ensure a manufacturer’s 
complete device interoperability; they are identical 
to the official registration testing completed by the 
Fieldbus Foundation. The kits are excellent tools for 
troubleshooting and debugging HI and HSE devices. 
Very recently, the Fieldbus Foundation has announced 
the release of its Host Test Kit DD Application Test 
Module. This powerful test kit includes hardware and 
software for testing the functionality of a fieldbus 
host and its conformance with the Foundation Host 
Interoperability Support Test (HIST) profile specifica- 
tion [43]. Thanks to the Host Test Kit DD Application 
Test Module, end users will benefit from significantly 
improved host-to-device integration. Foundation 
Fieldbus host suppliers will benefit from standardized 


test requirements and test cases for all hosts within a 
profile tested to the same requirements. 

• Tokenizer. Once a DD source file has been created, 
the developer uses a PC-based tokenizer tool to vali- 
date the syntax, dependencies, and other protocol 
and language rules. After verification and validation, 
the tokenizer generates a DD binary file that orga- 
nizes the information into a format accessible by host 
applications. Besides providing a compressed, easier- 
to-transfer file, the binary format also provides pro- 
tection against accidental changes using a simple text 
editor. Within the host application DD services, soft- 
ware unpacks the DD binary and displays the defined 
information to the user [37,44], 

CONCLUSIONS 

This chapter has given an overview of the main features con- 
ceived at the definition of the Foundation Fieldbus, pointing 
out the philosophy, which has driven the FF specifications. 
Since its definition, a lot of new technologies have been intro- 
duced in the ICT, ranging from transmission media to infor- 
mation modeling techniques; update of the FF specification 
was mandatory in order to integrate these new technologies, 
when they led to real advantages for the communication sys- 
tem. For this reason, the chapter tried to give an exhaustive 
overview about all the integrations already done and about 
all the work that is carried on at this moment to integrate 
more features. 
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